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gT ^_ pafeeft ^ r ^ gad oro a rlr Offing 



TSE ^7^r nt mention relates to eiectron.c commerce. 
M ore particularly, - present invention rentes to an 
electronic bin parent system with account ranging. 

„ has been common for Many years for consumers pay 
blll s by way of a personal checK «l*t» * the consumer to 

trie orae „„ m ™ lte rs interconnected 

in person, with the proliferate of computers 

v „,rticularly the Internet, consumers can 
to colter networKs, part ^ * ^ ^ ^ 

now pay biiis electron.cally. -« ^ 

not possible for a consumer, usmg a compu 

Lelt with a single payment system capable of paying .11 
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.. bU ls whether b, electronic means or by . Paper 
the consul's bills ^ oons olld,ted 

check, such a system now exists „.,. 

von, as described by ElflM— 
biu payment svs- sysm AND — . « 

patent Ho. 5,383,1 , „„ ICK s I»CIflM»G PAYMENT 

BIjECTROBICALLY POT« 

or ««.. " S nt system scribed 

though the consolidated hill ^ * 

■ .ul, significantly advanced the state 
by « _ uhich „ ay arise in 

it did not focus on sever ^ ^ 

impiementin, a consolidated h.l P V» ^ ^ 

automatical* paying — s 

^ isthat "p:^----- biu 

make mistakes in entering P 

P ay*ent system. ^ ^ ^ with 
Such a case arises wnen 

Kant is incorrectly entered. The payment system 

, merchant is who vlu use 

submit a correct account number ^ ^ 

thl5 account number to associe ~J ~ ^ 

Thus, a technique is neeae 
consumer. Thus, 

rtV , c account number, 
fitted consul s ^ ^ 

A data entry person may 

.rifles the merchant's name or parts 
correctly specks t ^ ^ ^ 

merchant's address. are 

♦ ion such as the merchant name, address, 
information sucn a* been 

, , ,4. the data entry stage. K 
typically mangled at the a 
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further observed that errors .ill often be made upon entry of 
the .* code. The merchant's name, address, and zip oode is 
typically retired by the payment system in order to, for 
example, retrieve merchant records fro. the Merchant database. 
If this data is incorrect, the parent system may be unable to 
retrieve the correct merchant's record for processing a 
payment. Thus, a technic is needed to correctly identify a 
merchant record notwithstanding the submission of erroneous 
merchant data. 

A consolidated bill pay-nt system must also have the 
capability to properly re.it paints to the same merchant at 

, Hance cen ter. Commonly a large commercial 
more than one remittance center. 

Q^ars^ will have several 
merchant, (e.g., shoe company, Sears) 

remittance centers distributed geographically so that 
vomers can submit bills to a center within their location. 
Thus, a technic is retired to ensure that consumer payments 
ar e remitted to the proper one of multiple remittance centers 

associated with the same. 

Advantageously, a consolidated payment system must also 
be a ble to handle the different processing formats and 
retirements of numerous separate merchant accounting systems. 
F or example, each merchant's account system may regu.re 
payment information, such as consumer account numbers, in a 
format different than that submitted by the consumer. For 
example, many merchant accounting systems will only accept an 
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account number with some portion of a consumer's iast name or 
th e consumer's zip code appended to the end of the account 
number presented by the customer. 

* merchant account system may even require an altered 
consumer account number which uniquely identifies the 
consumer. For example, two consumers, e.g.. spouses, may have 
identical account numbers, but the merchant accounting system 
may designate the account of each consumer uniquely, such as 
by combining the account number with the prospective 
customer's name. Additionally, it is not unusual for a 
merchant to have different account numbers for a single 
customer. For example, an account number on an invoice which 
g „es out electronically may be different from an account 
number for the same customer which goes out as a paper 
transaction- 

Thus, a consolidated bill parent system must be able to 

fnrmats reauired by the merchant accounting 
handle the various formats requirea y 

„v, a m- Accordingly, a technique is required 
system of each merchant. According x y , 

to transform payment data received from the consumer into a 
form compatible with a merchant-s accounting system. 



^j^vps of thp invention 
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nbnect of the present inven 
Accordingly, it i- »» ^ e receiving bill 

Mont sYS tem capable 01 

— : :::: :r. — , «. — - - 

payment data „ er chants. 

„.., uv paying their bills prese nt 
automatically P object o£ the P 

in particular, i ensu ring payments are 

• to provide a technique tor 
invention to pro 

.emitted to the proper remittan „ 

pro vide a bill Parent - ^ _ —s , an d in 

e „tered bill «~ . ^ reo ord based on 

particular to correct y data . 
rec eived ineormation »hich may „ 
- S 3tiU 3 £Ur0 ;r lishin, Payment information, 
pr0 vide a technique ^ ln a 

including a payor, account - ^ ^ 

£0 rmat acceptable to a part c ^ ^ 

It is another object of _ ^ „ ith . 

. me for validating a consumer . 
a technique tor v« 

merchant. x features of the 

M aitional objects, advantages, ^ ^ ^ ^ 
presentinvention U ill-»e-^^ foiiouingdetaUed 
art from this disclosure ^ ^ ^ 

aescription, - -11 as by P ^ pre£erred 

- t^e understood that the invention is 

embodiment (s) , ^ 
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„ot li.lt- —to. Those o f ordinary *iU in the art 
cess to the teachings herein will recognrse 

eBb oai„ents, as 

additional implementations, modmcatio 
well as other eields o £ use, which are ~ 
invention as disclosed and claimed herein and with respec 
which the invention could he of significant utility. 

t*™™^-^ —on, a 

In accordance with the P 

oommunications network couples a payor station, ^ » 
b ehalf - a consumer or corporate user, and a payee 

k <■ to a programmed computer, or possibly 
a merchant, to P 

distributed system of computers, which p 

s ts allowing them to communicate and exchange data 
reguests, . co ,„ unioations network may be of any 

between themselves. The comm Dn . ities 
ty pe facilitating the flow of information among the entities 

T^t.rnet To process payment 
such as a private network or the Internet. P 
reguests, a first station, e.g. a payer station, tran- 
..yment information, including name, address data 
a ",s account number with one of perhaps thousands . ^ 
and a second station, e.g. a payment processing server 
Lives this payment information and account number eve t 
, rt The first station initiates payment on behalf 

is The second station then processes the payment 
consumers. +.„ a 

• • a reauest to make a payment to a 
information by receiving a request 



IPDC: 463.1 33500-00003 



Docket NO.: 33500-00003 

paye e having a plurality of parent remittance centers, the 

r qu st including information identifying a payor account 

num ber with the payee, processes the account number to select 

a single remittance center of the plurality remittance centers 

• k ^nt is to be made, and then directs payment to 
to which payment is to 

the single pittance center. The correct remittance center 
i. determine, based on characteristics of the account nu^er. 
Th ese characteristics inciude any identifying information. 
s uch as any cognation of digits or alphanumeric characters, 
s uch as. for example, alphanumeric characters identifying a 

payor's telephone number. 

In a further aspect of the present invention, the second 
nation transforms the payor account numher into an aitered 
payor account number according to alteration rules. In a 
further aspect of the present invention, the second station 
processes the payment information to produce an eieven digit 

a r,rt accesses a database of payees, 
zip code for the payee, and accesses a 

=, r>»vpp record corresponding to 
typically merchants, to locate a payee recor 

the eleven digit zip code. 

The first station collects payment requests from a 
plur ality of consumers and feeds the requests to the second 
station. The first station and second station can be a 
computer or distributed network of computers. Typically, the 
second station is realized as a programmed general computer 
ha ving a storage device and a processor. The storage dev.ce 
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is configured to store a database of payee records and also 
includes alteration rules and validation rules for each payee. 
As will be understood by those skilled in the art, the storage 
device may be configured in any one of many arrangements to 
store and manage databases, and could include a long term bulk 
storage configuration, such as one or more hard disks. 

The alteration rules can specify a wide variety of 
formats and may be realized as templates specifying fields or 
values, or as instructions for combining information from 
different fields. Typically, an altered account number is 
formed by combining the account number with some part of 
payment information or other information related to the payee. 
For example, the altered account number may include a portion 
of the payor's name, a portion of the payor's address, or a 
portion of the payor's zip code combined with the account 
number . 

According to another aspect of the present invention, 
validation rules for the account number are stored, and a 
determination is made as to whether the received account 
number conforms with the validation rules. The validation 
rules identify the expected general format for any payor 
account number associated with a payee. Validation rules are 
preferably realized as templates specifying fields or values, 
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out may taxe on other forms, ana may even be algorithm. For 
example, a check digit algorithm could process the account 
„u»ber and compare the result to a check digit. 

Preferably, the general computer of the second station is 
a mainframe or mini computer or high powered workstation, hut 
oould he any other processing device capable of executing 
programmed instructions. Additionally, the general computer 
could be a distributed computer system in which various 
aspects of the system run on different platforms. The 
processor of the general computer is programmed to receive 
pay ment information and process the payment information to 
make a payment to a payee having a plurality of payment 
remittance centers, the revest including information 
identifying a payor account number with the payee. The 
processor then processes the account number to select , single 
remittance center of the plurality remittance centers to which 
payment is to be made. Payment is then directed by the 
processor to the single remittance center. 

In a further aspect of the present invention, the 
processor verifies the account number conforms to the 
validation rules, and transforms the verified account number 
into an altered account number according to the aiteration 



rules . 
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in a further aspect of the present inv ntion, the 
proc ssor receive payment information, processes the payment 
information, excluding zip code information, to produce an 
eleven digit zip code for the payee, access the database to 
locate a payee record corresponding to the eleven digit zip 
code, and then, preferably, makes an electronic payment to the 
payee after locating the payee record. 

The processor's programed instructions can be stored on 
a storage medium. This article of manufacture may be 
portable, a floppy disk, a hard disk, a CD Rom, or other 
storage medium. The processor reads the programmed 
instructions from the medium and in accordance therewith 
receives a request from a payor to make payment to a payee 
having a plurality of payment remittance centers, the request 
including information identifying a payor account number with 
a payee, processes the account number to select a single 
payment remittance center of the plurality of payment 
remittance centers to which payment is to be made, and then 
generate a signal to direct payment to the single payment 

remittance center. 

in another aspect of the present invention, the processor 
may also read additional programmed instructions from the 
ffi edium and in accordance therewith receives payment 
information including an account number for a payor, processes 
the payment information, excluding zip code information, to 
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produce an eleven digit zip code for the payee, and preferably 
accesses the database to locate a payee record corresponding 
to the eleven digit zip code, and then, preferably, makes an 
electronic payment to the payee after locating the payee 
5 record . 

In another aspect of the present invention, the processor 
may also read additional programmed instructions from the 
medium and in accordance therewith also verify the account 
number based upon validation rules for account numbers 
.0 associated with one of a plurality of payees, and preferably 
transform the account number into an altered account number 
based upon alteration rules of the one payee, and transmit the 
altered account number to the payee. 

Rrief Descr iption of Drawings 
L5 TIG. 1 is a system overview of a computerized bill 

payment system in accordance with the present invention. 

FIG. 2 is a diagrammatical representation of the 
remittance payment processor system of Figure 1. 

FIG. 3 is a flow chart illustrating merchant 
20 identification in accordance with the present invention. 

FIG. 4 is a block diagram illustrating how merchant 
identification accesses the merchant database. 

FIG. 5 is a flow chart illustrating account ranging in 
accordance with the present invention. 
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FIG. 6 is a flow chart illustrating account scheming in 
accordance with the present invention. 

n rr . r M rr1 - f,vr p^rrvina out the Inventio n 

FIG.l generally depicts a bill payment system including 
consumers 8, merchants 4, a batch file processing system 7, a 
remittance payment processor (RPP) 3, merchant banks 5, and 

consumer banks 6. 

A consumer, including a corporate user, (payor) is the 
individual or other entity for whom payments are actually made 
and whose account will be debited by the amount of the 
payment. The consumers 8 typically submit their payments 
electronically to batch file processing system 7. The batch 
file processing system 7 represents any computer or network of 
computers capable of collecting payment requests from the 
consumers 8. 

Consumer banks 6 either physically or electronically 
holds money on account for consumers 8. These accounts are 
debited by the amount of any payments made on behalf of the 
consumers 8. 

Merchants (payees) 4 are the persons or other entities to 
whom payments are made via the bill payment system on behalf 
of consumers. Merchants may include department stores, the 
phone company, the paper boy, a credit card company, as well 
as other persons and entities to whom payments are made by one 
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or more consumers 8. Merchants have accounts with merchant 
banks 5. 

The remittance payment processor (RPP) 3, as shown in 
Figure 2, includes a memory 16 storing programmed instructions 

5 for carrying out the functions of the RPP, a processor 17 for 
executing these instructions, and a merchant database 18 
storing information associated with the merchants. A batch 
file processing system 7 provides payment records collected 
from consumers 8 and transmits the batches of records to the 

10 RPP 3. 

A network 1 connects the above-stated entities making 
communications between them possible. The network may be of 
any type capable of facilitating the flow of information among 
the various entities. It could, for example, be a public 
15 telecommunication network, the Internet, or other type of 
communication network. The network 1 may also be physically 
realized as one or more networks. For example, in one 
possible embodiment, consumers 8 are coupled to batch file 
processing system 7 through one network and the batch file 
20 processing system is coupled to the remittance payment 
processor (RPP) through another separate network. 

In operation, consumers 8 make payment requests 
electronically and these payment requests are collected by the 
batch file processing system 7. The batch file processing 
25 system 7 then transfers the payment requests collected from 
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consumers 8 to the RPP 3 via the network 1. Payment 
information for a consumer will include several different 
types of information, such as the consumer account number, the 
merchant name, and address. 

FIG. 2 illustrates an overview of the process flow within 
the bill payment system of RPP 3. RPP 3 receives payment 
information from the batch file processing system 7, processes 
that payment information, and passes the processed information 
to a component 24 which then makes payments to merchants 4. 
A payment is implemented by crediting a merchant's account 
electronically with a bank or other financial institution, or 
transferring a check or draft to the merchant. A payment 
implementation also includes sending advice to the merchant. 
Advice is information on a bill payment presented to a 
merchant electronically in a form that the merchant's system 
can use to process the bill payment transaction and update the 
merchant's records. One possible mode of payment to a 
merchant is electronic funds transfer through the Federal 
Reserve Automated Clearing House (ACH) Network 26. Another 
electronic payment avenue is through the MasterCard RPS 
Network 30. Another remittance advice delivery mode is 
through Fax 22. Additionally, payment can also be made non- 
electronically to a merchant causing laser printer 28 to print 
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a check 32 or a draft 34. There is also a direct send 21 
capability whereby the payment system sends advice to a 
merchant 4. 

RPP 3 stores or processes several different record types 
5 necessary to the bill payment process. A merchant record 
contains all necessary information needed to forward a 
payment. This includes a merchant name, address, and zip 
code. A consumer record include a consumer name, address, zip 
code, and consumer account number. A payment r ecord will_ 
10 containin formation related jt o_jgayment , including_payee 
iden tification L _coP^i m p.r identification , and the d ollar amount , 
of the transaction . The merchant records are stored in a 
merchant database 18. All other records as well as programmed 
instructions which direct the operation of the RPP are stored 
15 in a memory 16. The memory 16 could also store the merchant 
database 18 if desired. 

After receiving payment records from the batch file 
processing system 7, the RPP periodically initiates a payment 
cycle 20 which process the records to generate information 
20 which will be used to credit merchant accounts and form advice 
for merchant systems. The processing flow of the billing 
cycle contains, in addition to other processes, three 
particularly important processes necessary for successful 
processing of each payment record. These processes are 
25 mer chant identification 19a, account ranging 19b, a nd account, 
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scheming igc^tygigal ly performed in this_ord er. In_the_£irst 
s tep of processing a payment record, merchant identificat ion 
a^empts to identify a merchantjnj^ 
based-on-lnfor^ 

^^^T systM^n^ center _ 

■^^ ^7o which the billing i nf °rm^onj^^ • 
a-la^Idl^Tr^mTttance oent & rJ :1 ^^ 1 J^^^^Il^ 
tl^hlr^^^ 

s-cS^gT^^ 

a "l^r^nTTcIoTdin g to_Jhej<^cJ^^ 

scl^nT^all^ 
proce^s-to^He^T^o^ 

^^^^^^^^T^^^to acco^s^iem^. 
"--"7^^^ payment cycle is a 

preferable embodiment of the RPP, a payment cycle can include 
the three processes of merchant identification 19a, account 
ranging 19b, and 19c, in any order or combination. In 
addition, these three processes may be performed 
independently, and could also be performed and packaged 
individually outside the RPP. These three processes will now 
be described in further detailed herein referring to FIGS 3-6. 

FIG. 3 illustrates merchant identification. Using 
merchant identification, the RPP 3 is able to retrieve the 
correct merchant record from merchant database 18 based on a 
consumer's payment record submitted with possibly erroneous 
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merchant name and address information, e.g., street address, 
city, state, zip code. It has been observed that data entry 
operators will often make errors in the merchant's street 
address and zip code. The RPP 3 is capable of mapping the 
mangled merchant information supplied in the payment record 
into the proper merchant record in the merchant database 18 
notwithstanding the errors in the merchant information. 
Merchant identification as described herein, can be used in 
any implementation where merchant information is likely to 
contain errors and must be mapped into an existing merchant 
record in the merchant database. 

RPP 3 initiates merchant identification by step 60 which 
retrieves a payment record from one of the payment records 
previously submitted by the batch file processing system 7. 
The^PP wi ll first attempt to retrieve a ^d« ntjr«c«d_^ 
The merchant database 18 by matching ^J^chant^^ 
^jj ^ records_of_th e^^ 

. 1fl _ Tf _ this is successfu1 ' the processing o£ the 

payment r e cord can continue to the payment dirertion s^stage, 
7T~^ Zment directions stage is There the RPP^et ermines^ 
^ nr^nTZyments. This stage includes account ranging 
l^sTeT below which determines the remittance center to 
which payment gets sent. lfJ^reJs J!1 o_^td , , the RPP 

J =ontinue^^ 
^^erchantj^^ 
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address ^ and zip code, into an eleven digit zip code^ Thatj^ 
the RPP produces an eleve n digit zip code base d^onjnerchant^ 
^~^_^ate^ ^B payment informati gnT In order to 
avail the merchant information which the inventors have 
5 determined to be mostly likely to contain errors, the received 
merchant street address and zip code are not considered. 
Hence, in step 66 the RPP 3 identifies an eleven digit zip 
code based only on the merchant's name, city, and state. 

Step 66 of merchant identification uses the indexing 
10 structure shown in Figure 4 to access one or more records from 
the merchant database 18. 

In step 66, the RPP 3 forms a 11 digit zip code index 82 
to associating the index entry with a merchant record in 
merchant database 18 via index 84. It may be possible that 
15 there is more than one merchant at a location identified by an 
eleven digit zip code. For example, there could be a 
remittance processing center on the floor of the building 
identified by the eleven digit zip code which handles payments 
for several merchants 4. In such a case, the RPP 
20 differentiates the correct merchant record from other possibly 
correct merchant records associated with the same eleven digit 
zip code by, after identifying merchant records indexed to the 
same eleven digit zip code, comparing some portion of the 
merchant's name, e.g., the first five characters with the 
25 characters of each merchant's name which has been combined 
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with the application zip code in the merchant index. The RPP 
3 is thereby able to uniquely identify the proper merchant 
record. 

If step 66 identifies a unique merchant record processing 
continues to step 64. However, if step 66 retrieves more than 
one merchant forming a group of records 86, then at step 67 
the RPP 3 will attempt to match one or more characters of the 
merchant's name 83 against the records 86 to identify a 
merchant record. If a match is found, processing continues to 
the payment directions stage 64. If there is no match, then 
the RPP will handle this contingency at step 68. If there is 
no merchant, the system may have provisions at step 68 for 
adding the merchant to the merchant database 18. 

f ig. 5 illustrates a payment direction stage, as 
perform ed in the preaEEBj-jeBfeP^^ 

invention, in which the RPP attempts to determine a remittance 
center to which payment is sent . __Th^PP_jdete^^ 
remittance^ centex^basjt^^ 

identification rules: lU^gth^f^ccountj^ 
zip code, 3) merc hant name, and^)^accgur^ajigina^ Each rule 
has in common that it identifies the remittance center based 
on some factor of the payment information. 

In Figure 5, the RPP 3 processes the payment record 
p resented in step 51 to determine on e of a plurality of 
remittance centers associated wi thjbh^ap^^ in 
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which to make payment. In step 53, the RPP chooses one of the 
above-mentioned four rules and at step 55 attempts to identify 
a remit tance^center. If j l remittance center is f oun d_at_gtep 
56, t hen the RPP dir ects_p avment to that remit tance center 58. 
If the RPP is unsuccessful in determining a remittance center, 
the RPP cycles back_t o step 53 _a nd__picks a_new rule for 
"Idintrfica ti^nT By this process, the syste m cycles through 
all combinations of rules that identify remittanc e cent ers fo r 
the merchant. 

in account ranging, the correct remittance center is 
determined based on some characteristic of the consumer's 
account number. Typically a large merchant, such as credit 
card company will have multiple remittance centers to which 
respective consumer payments must be submitted. The payment 
record contains information which may be used to identify a 
remittance center besides an account number, such as an area 
code of the payor's telephone number. A telephone phone 
utility might include each consumer's area code in the 
consumer's account number and require payments from all 
consumers within a particular area code be directed to a 
particular one of multiple remittance centers. A credit card 
company may require that payments from all consumers having 
the same first six digits in their account numbers be made to 
the same remittance center. 
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The payment direction process illustrated in Figure 5 is 
a preferred embodiment for determining payment direction. In 
this embodiment, the payment direction process includes 
account ranging as one of four possible methods of identifying 
a remittance center. However, in other embodiments, account 
ranging may be used in different combinations, or 
independently. 

FIG. 6 illustrates the steps for account scheming. In - 
certain cases, the consumer account number received by the RPP 
as part of the payment information may contain errors. Hence, 
the RPP has no way of checking the account number against a 
previously stored account number associated with, the 
applicable consumer to verify the accuracy of the received 
information . 

Using account scheming, the RPP receives, in step 12a, 
the consumer account number as part of the payment record. In 
step 42, the RPP checks to validate the account number. Then 
in step 46, the RPP alters the account number to correspond to 
a format required by a merchant's system 4 for processing. 

More particularly, the RPP validates and alters the 
consumer account number by storing separate business rules for 
each merchant which identify the expected general format for 
any consumer account number associated with that merchant. 
These business rules are stored as validation templates 40 in 
merchant database 18 for each merchant. The account number 
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received from the consumer is checked against the validation 
template to validate that the account number conforms to the 
general account number format to which an account number 
associated with the applicable merchant must conform. For 
5 example, the validation template for a merchant such as a 
credit card company may require an account number begin with 
the numbers -43" and be 18 digits long. Additionally, for 
some merchants the validation template will have check digit 
requirements. That is, the validation template can be used to 
.0 confirm that the received consumer account number conforms to 
a check digit after being run through a specific algorithm. 

in operation, the RPP 3 performs, in accordance with 
programmed instructions stored on the memory 16, the 
validation procedure by comparing in step 42 the received 
15 consumer account number for the applicable merchant received 
in step 12a with the validation template, say 40, for that 
merchant to test the validity of the account number. If that 
account number is not valid, the payment directions are 
rejected as not valid in step 43; otherwise, the account 
20 number is considered valid. 

Once the account number has been validated, it is then 
modified in step 46 so as to conform to alteration rules 44 
for the applicable merchant. The alteration rules 44 are also 
stored in database 18. The alteration rules 44 relate to the 
25 format of the consumer's account number in which the 



22 

IPDC: 463.1 33500-00003 



Docket No.: 33500-00003 

applicable merchant system requires to process a consumer's 
payment. Typically, alteration rules would specify an altered 
account number which includes a portion of a payor's name with 
the account number, a portion of the payor's address with the 
5 account number, or a portion of the payor's zip code with the 
account number. Alteration by the RPP 3 involves notifying 
the received account number which will be furnished, along 
with payment, to the merchant. For instance, some merchant 
systems require that the consumer's account number always end 
10 in -120". Hence, in such a case, the RPP 3, in accordance 

with programmed instructions stored on the memory 16, modifies 
the received account number to append "120" to the end of the 
alpha-numeric sequence of the received account number. Once 
the account number has been modified so as to conform to the 
15 format required by the merchant system, the altered account 
number 47 is then transmitted from the RPP 3 to the merchant 
4 via the network 1, along with the payment, in step 48. 

It will also be recognized by those skilled in the art 
that, while the invention has been described above in terms of 
20 one or more preferred embodiments, it is not limited thereto. 

Various features and aspects of the above described invention 
may be used individually or jointly. Further, although the 
invention has been described in the context of its 
implementation in a particular environment and for particular 
25 purposes, e.g. a bill payment system, those skilled in the art 
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will r cognize that its usefulness is not limited thereto and 
that the present invention can be beneficially utilized in any 
number of environments and implementations. Accordingly, the 
claims set forth below should be construed in view of the full 
5 breadth and spirit of the invention as disclosed herein. 

The present invention is not to be limited in scope by 
the specific embodiments described herein. Indeed, various 
modifications of the present invention, in addition to those 
described herein, will be apparent to those of skill in the 
10 art from the foregoing description and accompanying drawings. 

Thus, such modifications are intended to fall within the scope 
of the appended claims. 
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